Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/dhc/dhc-minutes-92nov.txt

Text File | 1993-02-17 | 6KB | 133 lines

Editor's Note: Minutes received 12/7/92

CURRENT_MEETING_REPORT_


Reported by Ralph Droms/Bucknell

Minutes of the Dynamic Host Configuration Working Group (DHC)

The Dynamic Host Configuration Working Group met twice in Washington.
In the first meeting, the Working Group reviewed the state of the
protocol specification.  Ralph Droms described several recent changes to
the specification documents, made in response to the IESG's review.
Comments about the changes were posted to the host-conf mailing list and
are available from the list archive in
sol.cs.bucknell.edu:dhcwg/host-conf-archive.  Two additional issues not
previously addressed by the IESG were raised by Philip Almquist in an
``in-the-hall'' meeting:  DHCP must permit server to disallow access to
network addresses by unauthorized clients, and DHCP servers should be
able to provide client-specific network parameters; i.e., DHCP servers
should not be required to provide the same parameters (e.g., DNS server)
to all clients on a subnet.

The Working Group approved of the changes to the specification
documents.  After several additional changes are completed, DHCP will be
resubmitted to the IESG for consideration as a ``Proposed Standard''.

There was a brief discussion of BOOTP/DHCP relay agent behavior relating
to the insertion of the client's subnet mask in DHCP messages by the
relay agent.  The Group concluded that DHCP servers must be aware of the
network topology and can, therefore, always determine the appropriate
subnet mask for a DHCP message.  Thus, there is no advantage in allowing
relay agents to supply the subnet mask.  The Group decided that
BOOTP/DHCP relay agents are not allowed to insert a subet mask into
BOOTP/DHCP messages.  Walt Wimer will modify the BOOTP/DHCP relay agent
document to reflect this decision.

The Working Group also discussed backwards compatibility with the use of
the `file' field in BOOTP. DHCP will continue to use the `file' field as
in BOOTP (except where overridden by the `overload' option [op[tion code
48]).  DHCP will also use `siaddr' to hold the address of the server the
DHCP client is to contact for further configuration (e.g., a TFTP server
from which the DHCP client may obtain a "boot file").  Wimer will modify
the BOOTP clarification document and Droms will modify the DHCP
specification to explicitly describe these uses of the `file' and
`siaddr' fields.

Next, the Working Group embarked on a lengthy discussion about the use
options and the interpretation of some options as ``vendor-specific''.
The concern is that some vendors may have difficulty in obtaining
allocation of option numbers from IANA for options that are specific to
that vendor.  The proposal was to define a ``vendor identifier'' option,
and a range of options as ``vendor-specific''.  The ``vendor-specific''
options would then be interpreted based on the ``vendor identifier''.
For example, if a client identified itself as a ``Bison Chip Computers''
client by including a ``vendor identifier'' option with value ``Bison

                                   1





Chip Computers'', the ``vendor-specific'' options would then be
interpreted according to ``Bison Chip Computers'' allocation of option
values.  Such a mechanism would give individual vendors freedom in
allocating options as they desired without having to go to IANA for new
options.

The Working Group took the proposal for a ``vendor identifier'' and
``vendor-specific'' options under advisement.  There was a
counter-argument that fewer than 50 of the available 128 options have
been used to date (128-254 are reserved for ``site-specific'' options),
so that the ``vendor-specific'' option mechanism may not be necessary.

Bob Gilligan suggested some modifications to Wimer's BOOTP/DHCP
clarification document to explicitly describe the interactions between
clients and servers in networks that may have both BOOTP and DHCP
servers.  In particular, DHCP servers must be configurable to disallow
the automatic allocation of network addresses in networks where clients
may receive responses from both BOOTP and DHCP servers.

In its second meeting, the Working Group took up the issue of a
server-server protocol to automate the replication and reallocation of
network address bindings.  Greg Minshall presented a specific proposal
that would provide redundant allocation, redundant reacquisition of a
previously allocated address and distributed extension of an existing
lease.

Greg also mentioned the use of SNMP as a configuration tool once DHCP
has provided sufficient configuration to the client to allow operation
of a transport protocol.  Droms suggested that Deering's work in
identifying all of the configurable parameters cited in the Host
Requirements documents should be forwarded to the appropriate MIB
working groups for their consideration.  The Working Group concluded
that DHCP should be kept as lightweight as possible, deferring to other
configuration mechanisms such as SNMP and TFTP wherever possible.

Attendees

Steve Alexander          [e-mail]
James Allard             [e-mail]
Richard Basch            [e-mail]
J. Nevil Brownlee        [e-mail]
Matthew Busche           [e-mail]
Michael Davison          [e-mail]
Peter DiCamillo          [e-mail]
Jon Dreyer               [e-mail]
Ralph Droms              [e-mail]
Robert Gilligan          [e-mail]
Nat Howard               [e-mail]
Ronald Jacoby            [e-mail]
Scott Kaplan             [e-mail]
Andrew Knutsen           [e-mail]
Kent Malave              [e-mail]
Greg Minshall            [e-mail]

                                   2





Drew Perkins             [e-mail]
Bradley Rhoades          [e-mail]
Fumio Teraoka            [e-mail]
Jim Thompson             [e-mail]
Walter Wimer             [e-mail]



                                   3